J 



EuropSlsches Patentamt 
European Patent Office 
Office europeen dee brevets 



Date of publication: 



(11) EP 0 987 628 A2 

EUROPEAN PATENT APPLICATION 

(51) Intci7: G06F 9/46, H04L 29/06 



(19) 



(12) 
(43) 

22.03.2000 Bulletin 2000/12 

(21) Application number: 99305658.9 

(22) Date of filing: 16.07.1 999- 



(84) Designated Contracting States: 

AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 
MC NL PT SE 

Designated Extension States: 
AL LT LV MK RO SI 

(30) Priority: 31.07.1998 US 126327 

(71) Applicant: SUN MICROSYSTEMS, INC. 
Palo Alto, California 94303 (US) 



(54) 

(57) A vehicle control connputer system uses Java- 
Beans™ to implement device interfaces. A vehicle con- 
trol center, having a processor and memory, provides 
user access to devices operating within the vehicle. The 
manufacturer of such devices provides a JavaBean™ 
interface stored with the device. When a device is in- 
stalled in the vehicle, the processor or other control el- 
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ement of the vehicle control center becomes aware of 
the installation and requests or otherwise receives the 
stored JavaBean™ interface from the device. A data 
structure is used to maintain information about interfac- 
es for devices. The vehicle control center can then use 
the interface as received or replace it with a different 
interface already stored in memory by changing the con- 
tents of the data structure. 
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Description 

BACKGROUND OF THE INVENTION 
s Field of the Invention 

[0001] The invention relates to computer control of user devices and. more particularly, to the use of Java Beans™ 
for providing centralized control of attached devices in a vehicle network. 

10 Description of Related Art 

[0002] As computer controlled devices become nrrare pen^asive. it is not unexpected that such devices would spread 
to traditionally mechanical domains such as automotive vehicles, A network vehicle was demonstrated at the Comdex 
Trade Show in November of 1997. That vehicle had a central computer which was used to control several attached 
15 devices. 

[0003] Various manufacturers have been developing and deploying bus architectures suitable for use in a vehicle. 
[0004] Computer systems are known which permit 'plug and play" operation. When a new device is attached to the 
computer bus. its presence is detected and it is automatically added to the list of devices known to the CPU to be on 
the bus. 

20 [0005] Object oriented programming languages and object oriented development environments are known in the art. 
[0006] JavaBeans™ and the Java Development Kit™ are well known products available from Sun Microsystems. 
JavaBeans™ is an architecture and platform neutral application programming interface for creating and using dynamic 
Java components. Application developers can use a variety of development tools, such as a Java Development Kit™ 
to assemble custom applications from fully portable JavaBeans™. 

25 

SUMMARY OF THE INVENTION 

[0007] The invention is directed to methods, apparatus, systems and computer program apparatus using Java- 
Beans™ for implementing device interfaces in an vehicular computer system. In such a system, a vehicle control center, 

30 having a processor and merrrory, provides access to devices operating within the vehicle. The manufacturer of such 
devices provides a JavaBean™ interface stored with the device. When a device is installed in the vehicle, the processor 
or other control element of the vehicle control center becomes aware of the installation and requests or otherwise 
receives the stored JavaBean™ interface from the device. A data structure is used to store information about the 
interfaces. The vehicle control center can use the data structure to use one of the interfaces as received or replace it 

35 with a different interface already stored in memory. In this way, plug and play and hot plug and play functionality can 
be achieved. 

[0008] The foregoing and other features, aspects and advantages of the present invention will become more apparent 
from the following detailed description of the present invention when taken in conjunction with the accompanying draw- 
ings. 

40 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0009] The present invention will be better understood from the following description in which: 
[0010] Figure 1 is a view of an automobile showing an exemplary arrangement of components for a network vehicle 
45 in accordance with the invention. 

[0011] Figure 2 is a block diagram of an exemplary vehicle network in accordance with the invention. 

[0012] Figure 3 is a block diagram of an exemplary vehicle control center shown in Figure 2 in accordance with the 

invention, 

[0013] Figure 4 is a diagram illustrating an exemplary software architecture for the vehicle control center shown in 
so Figure 3 in accordance with the invention. 

[0014] Figure 5 is a bkx:k diagram of a first exemplary device attached to a vehicle network in accordance with the 
invention. 

[001 5] Figures 6A and 68 show an exemplary alternative device attached to a vehicle network and a corresponding 
software architecture for the alternative device, respectively, in accordance with the invention. 
55 [0016] Figure 7 illustrates a preferred way in which information can be stored in ROM (Figure 5) and in memory 
(Figure 7) in an attached device in accordance with the invention. 

[0017] Figure 8 illustrates a preferred process for developing and storing JavaBeans™ in accordance with the in- 
vention. 
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[0018] Figure 9 is an inustratbn of an exemplary graphical user Interface used in a network vehicle in accordartce 
with the invention. 

[0019] Figures 10A-10D illustrate stages by which a vehicle control center can obtain a standard device interface 
from an attached device tn accordance with the invention. 
5 [0020] Figures 11 A and 11 B are flow charts of processes used to carry out the process described in conjunction 
with Figures 10A-10D in accordance with the invention. 

[0021] Figure 12 is a flow chart of a preferred process for handling one or more standard device interfaces received 
over a network or bus in accordance with the inventton. 

[0022] Figure 13 is a flow chart of a process used to select an interface from a plurality of interfaces in accordance 
10 with the invention. 

[0023] Figure 14 is a flow chart.of a process for removing a device from the network in accordance with one aspect 
of the invention. 

[0024] Figure 1 5 is an illustration of a simple data structure used for storing information about objects in conjuncton 
with JavaBeans™. 

15 [0025] Figure 16 is an illustration of an expanded data structure prefered for use in carrying out the invention. 
[0026] Figure 17 is a flow chart of a process for automatically removing devices from the network in accordance 
with the invention. 

[0027] Figure 18 is a flow chart of a process for changing interfaces or components of an interface. 
20 NOTATIONS AND NOMENCLATURE 



[0028] The detailed descriptions which follow may be presented in terms of program procedures executed on a 
computer or network of computers. These procedural descriptions and representatbns are the means used by those 
skilled in the art to rrK>st effectively convey the substance of their work to others skilled in the art. 

25 [0029] A procedure is here, and generally, conceived to be a setf-consistent sequence of steps leading to a desired 
result. These steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, 
these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, com- 
pared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to 
. these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It shoukJ be noted, however, 

50 that all of these and similar terms are to be associated with the appropriate physical quantities and are merely con- 
venient labels applied to these quantities. 

[0030] Further, the manipulations performed are often referred to in terms, such as adding or comparing, whk;h are 
commonly associated with mental operations performed by a human operator No such capability of a human operator 
is necessary, or desirable in most cases, in any of the operations described herein which form part of the present 
55 invention; the operations are machine operations. Useful machines for performing the operation of the present invention 
include general purpose digital computers or similar devices. 

[0031] The present inventton also relates to apparatus for performing these operations. This apparatus may be spe- 
cially constructed for the required purpose or it may comprise a general purpose computer as selectively activated or 
reconfigured by a computer program stored in the computer The procedures presented herein are not inherently related 
^0 to a particular computer or other apparatus. Various general purpose machines may be used with programs written in 
accordance with the teachings herein, or it may prove more convenient to construct more specialized apparatus to 
perform the required method steps. The required structure for a variety of these machines will appear from the de- 
scription given. 



^ DESCRIPTION OF THE PREFERRED EMBODIMENT 



[0032] Figure 1 is a view of an automobile showing an exemplary arrangement of components of a networic vehicle 
in accordance with the invention. The vehicle 100 contains a vehicle control center 110 which serves as a master to a 
bus 1 20. A plurality of attached vehicle devices 1 30 are also connected to the bus to be controlled by the vehicle control 
so center. 

[0033] Figure 2 is a block diagram of an exemplary vehicle network in accordance with the inventran. The vehicle 
control center 110, as noted in conjunction with Figure 1 , controls bus 120. A plurality of devices 200, 210, 220, 230, 
240 and 250 are illustrated as exemplary attached devices that might commonly be found in a network vehicle. Device 
200 shows a cabin lighting interface by which the vehicle control center can be used to control the lights in the cabin 
55 of a vehicle. By way of entertainment, a CD player 220 is shown and an AM/FM radio and tape player 230. Each of 
these devices will use the services of amp/speaker unit 210. The amp/speaker component 210 will amplify and provide 
sound output from the CD player and from the AM/FM radio and tape player 230 to the passengers within the passenger 
cabin. A global positioning satellite system receiver 240 can be used to provide navigation informatton to the driver or 
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other occupants ot the vehicle. A heating/air conditioning unit 250 can be controlled using the vehicle control center 
to set the appropriate environmental conditions within the passenger cabin. Other attached devices can be used in the 
network vehicle. These include radar, air bag activation and status, video cameras, emergency rescue, alarms, anti- 
theft system, odometers, gyroscope, route guidance, access control, location transponder, video games, an internet 
5 connection, a digital multimedia broadcasting receiver, telephone receivers, digital video decoders and recorders, a 
digital audio broadcasting receiver, voice recognition systems, a cellular telephone handset either directly connected 
or linked via infrared, a digital cell phone module and a gateway to other buses. These are just exemplary of the many 
different kinds of attached devices which can be connected to the bus and controlled using the principles ot this inven- 
tion. 

10 [0034] Figure 3 is a block diagram of an exemplary vehicle control center 1 1 0 shown in Figure 2 in accordance with 
the invention. A CPU 300 and memory 310 are connected to bus 120. A touch screen display 330 is connected to the 
bus over a display interface 320. The computer bus 120 may be optionally connected to one or more vehicle networks 
through interlace 340 to attached devices. Altematively, the attached devices rriay be directly connected to the computer 
bus. Other configurations are possible, but this configuration provides the basic functionality for a vehicle control center. 

IS [0035] Figure 4 is a diagram illustrating an exemplary software architecture for the vehicle control center shown in 
Figure 3 in accordance with the invention. Personal Java (400) runs on top of an operating system 430 and implements 
a virtual machine in the usual Java manner. The plurality of JavaBeans^ 410 are stored and may be selectively 
activated for carrying out the control functions in accordance with the invention. One or more applications may also 
be run on the virtual machine. 

20 [0036] Figure 5 is a block diagram of a first exemplary devk;e attached to a vehicle network. Devices attached to 
the network bus 1 20, such as attached vehicle device 1 30 are typically run by a device controller 500. A device controller 
can be implemented as a finite state machine or as simple logic responding to the bus state. In the simplest implemen- 
tation, illustrated here, a memory device such as ROM 510 stores information about the device and in addition, in one 
embodiment, contains a plurality of JavaBeans™ 520 for uploading to the vehicle control center over bus 120. 

25 [0037] Figures 6A and 68 show an exemplary alternative device attached to a vehicle network and a corresponding 
software architecture for the alternative device, respectively, in accordance with the invention. A more sophisticated 
attached device 600 contains its own CPU or controller and memory 620 connected to the bus 120.- In this particular 
implementation, embedded Java 630 can be run using CPU 610. A standard application programming interface (API) 
for automotive applications can be defined to standardize the programming interfaces to automotive devices. One or 

30 more Java™ objects conforming to the API. hereinafter called standard device interfaces 640 are stored as Java- 
Beans™ in the memory space of the attached device. 

[0038] The embedded Java platform is an implementation of the Java platform that is customized for embedded 
devices, which typically have no display and limited user input/output capabilities. Personal Java is a more extensive 
subset of Java for devices which include a display and better user I/O. The Figure 5 device does not need a version 

3S of Java at all in the attached device. 

[0039] Figure 7 illustrates a preferred way in which information can be stored in ROM (Figure 5) or stored in memory 
(Figure 6) in accordance with the invention. Typically, a device ID 700 will be stored The device ID may contain 
information such as an identification of the manufacturer 710, a model number 720, a serial number of the device 730 
and other information, in one embodiment, one or more standard device interfaces 740, such as standard device 

"^0 interface 1 or standard device interface N may be stored. In a preferred embodiment, each standard device interface 
includes a control bean for the execution of functionality to be performed in the vehicle control center to control the 
device with which the control bean is associated as well as a GUI bean which implements a graphical user interface 
by which the control functionality of the control bean may be exercised. 

[0040] As an alternative to storing a control bean 750 and a GUI bean 760 or other beans associated with the standard 
45 device interface 740, the memory device or ROM may store a network address such as a uniform resource locator 
(URL) from which the appropriate manufacturer's interface may be downloaded. This permits the nnanutacturer to 
update a user interface on a dynamic basis and ensure that the most recent version of the manufacturer device interface 
is downloaded when a device is installed. This also reduces the ROM space required for storing the manufacturer's 
interface information and reduces the cost of the attached end device. 
so [0041] One should note that there are a number of ways in which the standard device interfaces or custom interfaces 
can be installed in the vehicle control center. They can be pre-instalted in the vehicle control center when it is installed 
in the vehicle. Additionally they can be requested and downloaded from the attached devices as described more 
hereinafter. They can be loaded from a diskette. CDROM, EPROM or other memory medium into the vehicle control 
center. They can be received over a network link from a URL address which address is either downloaded from the 
ss attached device or entered manually, and they can be input over an I/O link, such as an infrared port to the vehicle 
control center. 

[0042] Figure 8 illustrates a preferred process for developing and storing Java Beans™ in accordance with the in- 
vention. A developer develops software to be implemented in a bean using, for example, the Java Development Kit™. 
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The state of the bean and the code associated with the bean can be serialized and stored, using a standard call provided 
with the Java Development Kit^. It can of course be done equivalently using software developed by others for that 
purpose. The serialized bean is then stored (820) in memory for use as described in this specification. 
[0043] Figuro 9 is an illustration of an exemplary graphical user interface used in a network vehicle in accordance 

5 with the invention. In a preferred embodiment, the vehicle control center uses a touch screen display 330. The touch 
screen display is configured in a plurality of different ways to form a reconfigurable dashboard. In the exemplary GUI 
implementation shown in this Figure, a number of interfaces are selectable by touching buttons associated with the 
bottom row. Activation of one of the buttons on the bottom row will select the particular interface to be displayed in the 
space above the t>ottom row. In the Example shown in Figure 9, the interface for the sound system has been activated 

10 by touching button 910. The fact that button 910 has been activated is indicated by the enhanced border around the 
button. When other buttons are selected, they will be similarly enhanced and the border around the sound system 
button 910 will revert to a nornoal outline. Each of the buttons shown on touch screen 330 can be implemented as an 
individual Java bean. JavaBeans™ can contain other JavaBeans™ in a hierarchical fashion. Accordingly the entire 
graphical interface display area of touch screen 330 can be implemented using JavaBeans™ contained within one 

IS graphical user interface Java bean. 

[0044] Along the left margin of the graphical interface display area are a plurality of buttons for selecting an appro- 
priate sound function. In this case, the FM front end source has been selected as indicated by the enhanced boarder 
around button 920. Other selections include a CD player source, a tape player source and an AM radio front end. 
Volume control, adjustment of treble and bass, channel selection and scanning are also implemented. A display element 

20 940 shows the particular source selected and window 930 shows the frequency of the station selected when in this 
mode. It is particularly instructive to note that many of the beans used to implement this graphical user interface may 
be reused in implementing the other interfaces for the CD, the tape, and the AM radio selections. Thus, the user of 
JavaBeans™ is provided with a powerful way to construct a graphical user interface. One should also note that each 
of the control functions, such as volume and tuning, Invokes underlying functionality which would typically be part of 

2B the control bean associated with the graphical user interface bean used to implement the graphical interface display 
area. 

[0045] Figures 10A-10D illustrate stages by which a vehicle control center can obtain a standard device interface 
from an attached device in accordance with the invention. Figure 10A illustrates the state in which two devices A and 
B have been attached to the bus 120. A Java bean 1 0OOA represents an interface to devrce A and a Java bean 1 0OOB 

30 represents an interface to device B. In Figure 108, a new device is shown added to the bus 120. It contains within it, 
as discussed previously, a standard device interface for the new device, such as one provided by a manufacturer. 
However, that standard device interface, 1000C, has not been loaded into the vehicle central control 110. As discussed 
herein, the vehicle central control sends a request over the bus 120 to newly connected device C requesting download 
of its standard device interface. In response to this request, the standard device interface 1000C is uploaded from the 

3S attached device to the vehicle control center 110 where it is stored. Figure 100 shows the final state in which the 
control beans 10000 are stored in the vehicle control center for use in controlling device C over the bus. 
[0046] Figures 11 A and 118 are flow charts of processes used to carry out the process described in conjunction 
with Figures 10A-10D in accordance with the invention. In Figure 11A, the vehicle control center detects (1100) a 
new device. This can be done in any of the ways used in conjunction with normal plug and play detectran. Typrcally 

40 this will occur upon boot-up. The vehicle control center then sends a request to the new device to download the standard 
device interface (1 1 0). The new device then sends one or more standard device interfaces to the vehicle control center 
(1120). The vehicle control center receives and stores (1130) the one or more standard device interfaces as discussed 
more in conjunction with Figure 12. This particular form of the invention is preferred where hot adaptation of the bus 
configuration is not desired. 

45 [0047] Figure 118 shows a process which is preferred when hot reconfiguration of the bus is desired, that is, addition 
of devices to the bus without rebooting. This will be referred to as hot plug and play When a device is connected to 
the bus during operation (1140), the device accesses the bus and sends its device ID (1150). The attached device 
then waits for a request from the vehicle control center and. if such a request is received, the vehicle device sends 
one or more standard device interfaces to the vehicle control center (1160). 

50 [0048] It may be that the vehicle control center already contains a standard or custom interface for the particular 
device identified by the device ID. If that is the case, there wilt be no need to request the download of the interface 
from the attached devk;e. If, however, the vehicle control center does not contain an interface for running the identified 
device, it can be requested and uploaded from the attached device to the vehicle control center. 
[0049] Figure 12 is a flow chart of a preferred process for handling one or nrK>re standard device interfaces received 

55 over the network or bus in accordance with the invention. When the vehicle control center receives one or more standard 
device interfaces (1200), preferably as one or more JavaBeans^, it checks to see if a prefen-ed interface already has 
been stored for the device (1210). If there has been (1210-Y), the preferred interface will be used and the uploaded 
interface optionally discarded (1220). If there is no preferred interface already stored for the device (1210-N), the 
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vehicle control center will determine whether plural interfaces have been received (1230). If only a single interface has 
been received (1230-N), that interface will be used to control the attached device (1240). If a plurality of interfaces are 
received (1230- Y), one will activate the interface selection mechanism shown in Figure 13 (1250) and then use the 
selected interface (1260). 

5 [0050] This process allows for customized interfaces for a particular device to be used in preference to a standard 
device interface. For example, although a particular CD player may come with a standard interface package, when it 
is integrated into a vehicle, for example, into a Cadillac™ by General Motors(8), the vehicle manufacturer may have 
certain standards for look and feel which it desires to have consistent across all attached devices. In this case, the 
manufacturer of the vehicle would install GUI beans into the vehicle control center which would be used in preference 

10 to the GUI bean provided by the attached device manufacturer. These GUI beans may use the control beans provided 
by the device to access the device's capabilities. Further, the manufacturer may wish to preinstall a plurality of standard 
device interfaces which can be selectively applied by a user of a vehicle depending on the users preferences. 
[0051] Figure 13 is a flow chart of a process used to select an interface from a plurality of interfaces. In order to do 
this, a list of each interface stored in the device is presented (1300) and a prompt given to a user to select one of the 

IS listed interfaces. In a preferred embodiment, each of the stored interfaces is listed in an expanded data structure as 
discussed more hereinafter In conjunction with Figure 16. The user then selects (1310) the desired device interface 
to use and the process returns (1320). 

[0052] Figure 14 is a flow chart of a process for removing a device from the network. When a device is removed 
from its bus connection (1400), the vehicle control center detects that a device previously installed is no longer con- 
20 nected (1410). This can be done, preferably, using the process described in conjunction with Figure 17 although there 
are several commonly known ways of detecting that a device has been removed. When a device is detected as having 
been removed, the device interface, previously received from the device is removed from memory (1420) and the data 
structure is updated to remove the device entries (1430). 

[0053] Figure 15 is an illustration of a single data structure used in conjunction with JavaBeans™. In this example, 
25 the data structure 1 500 is a simple text list of key-value pairs. It contains a field 1 51 0 which describes an object name 
(a key) and a field 1 520 containing a value associated with the object name. In this case, the value can be a reference 
or a handle to the object named in column 1510. As discussed herein, this data stojcture can be used to detect removal 
of objects from the bus or to add objects received over the bus from attached devices. The use of the data structure 
in accordance with the inventbn includes the use of the data structure for scanning to see whether a device is still 
30 attached to the bus as well as adding names to the data structure v^rtien standard device interfaces are uploaded from 
the attached devices and stored in the vehicle control center. 

[0054] Figure 16 is an illustration of an expanded data structure preferred for use in carrying out the invention. The 
expanded data structure goes beyond a simple list of key-value pairs. In this implementation, there is a field 1610 in 
which a device type may be identified, a field 1620 in which a control bean reference may be included, a field 1630 in 

3S which a GUI bean reference may be listed and a field 1 640 which indicates a preferred interface to be used when plural 
beans for control and/or GUI purposes are present. While This data structure is illustrated in table form, the same 
information can be stored in other ways, such as a hierarchical tree. An interface is a partrcular object type defined in 
a Java source file. It defines labels for a set of method calls, but the instantiatbn or code which executes the method 
calls is separate. The instantiation code is preferably in the form of a Java bean. Thus, associated with a particular 

40 device type (1 610) may be one or more interfaces, such as those shown in 1620 and those interfaces may be instan- 
tiated by one or more JavaBeans^" listed in column 1630. 
[0055] For example, a Java interface might have the following appearance: 
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interface CDPlayer { 
start 0; 
stop 0; 

play track (int n); 
play disk (int n) 



The start function from the interface might be implemented as follows: 
Class my_CDPlayer implements CDPlayer { 
start 0 { 

20 send_start_command_over_bus(); 

} 

} 

25 

[0056] The visual component for implementing the CD player of this example might be implemented as follows: 
Class my_CDPlayer implements CDPlayer, 

30 

Java.awt.Component { 

\ 

35 [0057] One should note that the interface contains no execution code but does define the calls or comnnands used 
with the interface. An actual JavaBean™ object implements the interface. Thus, most of the API consists of interface 
definitions which are implemented by the actual code defined by the manufacturer of the attached device and provided 
as part of the control bean and GUI beans uploaded from the attached device. 

[0058] Figure 17 is a flow chart of a process for automatically removing devices from the network in accordance 
40 with the invention. Upon start-up, if normal plug and play is used and optionally (when hot plug and play is used) 
periodically thereafter (1700), for each object representing a device in the data structure (1710) a check will be made 
if the device is still attached (1740). If it is. the next object will be considered (1730). If it is not (1740-N), the object will 
be deleted from the data structure (1750). 

[0059] Figure 18 is a flow chart of a process for editing interfaces or components of an interface. When an interface 
45 function is selected (1 800) a list of device types is presented from which a selection nnay be made. When the selection 
is made (1810), a list of JavaBeans^" associated with the selected device type are displayed (1820). These can be 
obtained from the enhanced data structure shown in Figure 16. The particular beans desired to instantiate the devbe 
interface are then selected (1830) and the enhanced data structure Is modified to reflect the user selections (1840). 
[0060] Thus, there have been disclosed herein techniques for using JavaBeans™ to provide for plug and play and 
^0 hot plug and play functionality and for allowing plug and play ope rat bn to occur even where the vehicle control center 
has no a priori knowledge of the type of device being attached to the bus. 

• [0061] Although the present invention has been described and illustrated in detail, it is clearly understood that the 
same is by way of illustration and example only and is not to be taken by way of limitation, the spirit and scope of the 
present invention being limited only by the terms of the appended claims and their equivalents. 
^ [0062] It will be understood from the foregoing that the described vehicle network that uses JavaBean^ components 
is one particular example of a configuration to be networked in a vehicle, wherein the vehicle device 1 30 and the vehicle 
controller 1 1 0 are operable to communicate interfaces using at least one platform independent, object oriented, software 
component so as to achieve a plug and play arrangement. For a fuller discussion of the component nature of Java- 



7 



EP 0 987 626 A2 



Beans™ and Java generally, reference is directed to The Java Tutorial. ISBN 0-201 -63454-6, Addison Wesley. Reading, 
MA USA 



Clalmd 

1 . An automotive vehicle comprising: 

a. a communications medium; 

b. one or more devices connected to said communications medium, each device controllable over said medium; 

c. a vehicle control center, connected to said medium, said vehicle control center Including a control element 
and memory, said memory including one or more JavaBeans™ for controlling at least one respective device, 
in which said control element is configured to detect connection of a device to said communications medium 
and obtain a JavaBean™ interface from said device. 

2. The vehicle of claim 1 , in which said control element periodically checks for new devices connected to said medium. 

3. The vehicle of claim 2 in which said vehicle control center contains a data structure of connected devices and said 
control element adds a device to said data staicture when a new device is detected. 

4. The vehicle of claim 3 in which said data structure is an object data structure running on said control element, 

5. The vehicle of claim 3 in which said data structure is a database of infornrmtion about objects. 

6. The vehicle of claim 5 in which said database includes information about the device type associated with an object. 

7. The vehicle of claim 6 in which said object Includes information about the type of object. 

8. The vehicle of claim 5 in which said database includes information about whether the object is preferred over other 
objects of the same type. 

9. The vehicle of claim 5 in which said database includes fields for information about control beans and GUI beans 
associated with a particular device type. 

10. The vehicle of claim 1 in which a device newly connected to said communications medium contends for access 
to said medium and, when access is obtained, downloads one or more Java Bean™ interfaces to said control 
element. 

1 1 . The vehicle of claim 1 in which said vehicle control center contains a data structure of connected devices and said 
data structure is used to scan devices listed in said data structure to determine whether listed devices are still 
connected to said communications medium. 

12. The vehicle of claim 11 in which said vehicle control center removes a JavaBean™ interface when a device listed 
in said data structure is no longer connected. 

13. The vehicle of claim 11 in which said vehicle control center marks a JavaBean™ interface for overwriting when a 
device listed in said data structure is no longer connected. 

14. The vehicle of claim 1 in which said vehicle control center includes a touch screen display and said Java Bean™ 
includes a graphical user interface (GUI) for interacting with said touch screen display 

15. The vehicle of claim 6 in which said GUI is a JavaBean™. 

16. The vehicle of claim 2 in which said JavaBean™ includes a control bean for controlling said device. 

17. The vehicle of claim 1 in which said control element is a processor running Personal Java™. 

18. A method of installing a device to become part of an vehicle computer system, comprising the steps of: 
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a. detecting that a device has been connected to said computer system; 

b. requesting a JavaBean*™ interface from said device; 

c. storing said JavaBean™ interface; and 

d. entering information about said interface in a data structure. 

5 

19. The method of claim 18 in which said device automatically identifies itself to said vehicle computer system when 
it is connected to said computer system. 

20. The method of claim 1 8 in which said computer system checks for devices newly added to said computer system, 

10 

21. The method of claim 18 in which said data structure is used to check whether devices are still connected to sakJ 
computer system. 

22. A method of installing a device to become part of a vehicle computer system, comprising the steps of: 

IS 

a. receiving an interface from said device. 

b. checking for other stored interfaces for said device, and 

c. selecting a desired interface to use with said device. 

20 23. A method of uninstalling a device from a vehicle computer system, comprising the steps of: 

a. detecting that a device has been removed; and 

b. removing one or more interfaces associated with said device. 

2S 24. The method of claim 23, in which the step of detecting includes the step of checking each device listed in a data 
structure to determine if said device is still connected to said computer system. 

25. A product for controlling an automotive computer system, comprising: 

30 a. a memory medium; and 

b. a series of instructions, stored on said memory medium, for causing said system to detect that a device has 
been connected to said computer system, for requesting a JavaBean^" interface from said device, for storing 
said JavaBean™ Interface; and for entering information about said interlace in a data structure. 

3S 26. A product for controlling an automotive computer system, comprising: 

a. a memory medium; and 

b. a series of instructions, stored on said memory medium, for receiving an interface from a device, checking 
for other stored interfaces for said device, and selecting a desired interface to use with said device. 

40 

27. A product for controlling an automotive computer system, comprising: 

a. a memory medium; and 

b. a series of instructions, stored on said memory medium, for detecting that a device has been removed from 
^ said system; and 

c. removing one or more interfaces associated with said device. 

28. A user device configuration to be networked in a vehicle, comprising at least one vehicle device (1 30) and a vehicle 
controller (110) each having an individual communications processing platform (400, 500. 600) for operation in a 

50 vehicle to enable the devk:es to communicate with one another through an in-vehicle communications medium 
characterised In that said devices are operable so as to communicate an interlace from the vehicle device to the 
vehicle controller using at least one platform independent, object oriented, software component such as to provkJe 
plug and play functionality for the vehicle device when connected to the vehicle controller through the communi- 
cation medium. 

55 

29. A configuration according to claim 28 wherein the software component comprises a JavaBean^ (410, 520). 
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